FYI @EgorBo
cc @dotnet/jit-contrib

The class layout rewriting isn't happening just yet, need to look at that more closely. We are OK even w/o rewriting since the backing field is a byref. Also I should perhaps restrict this more tightly to spans and make recognition of the span pointer fields simpler.

Some examples where we can stack allocate:

int SpanCapture()
{
    Span<int> span = new int[128];
    span[10] = 100;
    return Use(span);
}

int SpanCapture2(int[]? x)
{
    Span<int> span = x ?? new int[128];
    span[10] = 100;
    return Use(span);
}

and one where we can't:

Span<int> SpanEscape()
{
    int[] x = new int[128];
    Span<int> span = x;
    span[10] = 100;
    Use(span);
    return span;
}

This still has existing limitations (array must be known-size, small, and not allocated in a loop). But this along with #112168 gives us the ability to generally replace span captured stackallocs with safe constructs that can flexibly allocate on stack or heap depending on policy.

The analysis does not directly generalize to other struct cases -- non-ref structs can be on the heap, and ref struct may allow their gc ref fields to be extracted and methods that mutate those fields will not be using checked barriers. But other byref-likes that don't have any object ref fields should be optimizable in the same way (if there are any such, aside from Span<T>).

Some interesting diffs (not a lot, but some)....

@jakobbotsch pointed out that a callee like I below can return the span, which means we can't simply say the argument doesn't escape.

Added checking for this but it seems awfully convoluted.

• If the return value is a retbuf we try and verify that the retbuf is a local that has byref fields. If so we model the call as an assigment of the span local to the retbuf local.
• If the call returns a struct by value and the value can have byref fields we defer to the parent.

Handles cases like these:

Span<int> I(Span<int> x) => x

int SpanCapture3(int[]? x)
{
    Span<int> span = x ?? new int[128];
    span[10] = 100;
    return Use(I(span));
}

int SpanCapture4()
{
    Span<int> span = new int[128];
    span[10] = 100;
    Span<int> x = I(span);
    return Use(x);
}

Span<int> SpanEscape2()
{
    int[] x = new int[128];
    Span<int> span = x;
    span[10] = 100;
    return I(span);
}

Something similar is needed for ref/out params.... NYI.

Seems to be some issues related to ValueStringBuilder. Investigating...

Debugged into one failure. There is a span-captured box, via

and since the span does not escape, and the box is the span's pointer, we think the box also does not escape, and so stack allocate it.

Later on a callee extracts the object from the span and passes it to a runtime helper, which blows up.

[adding more details]

The capture happens here:

Root (boxes):

https://github.com/microsoft/perfview/blob/99a0c8976174c6d207fd63b11943661da865f435/src/TraceEvent/TraceEvent.cs#L474-L477

Intermediary (captures box in span):

Regex test failures seem to be from stack allocation here:

I suspect CharsToStringClass can read off the end of the array if there's just a one element non-ascii character array (though I have yet to prove it). Normally 1 element char arrays (on the heap) have some excess trailing zero bytes since the heap allocation granularity is 4 or 8 bytes. But the stack array allocations are not being rounded up and there is storage just past the character that is not zeroed.

cc @EgorBo -- subtle unsafe issue?

Hmm, maybe that's not it (though seems like we should pad arrays) -- we are stack allocating an array and then tail calling and passing the span-captured array as an arg. That's more likely the problem.

Hmm, maybe that's not it

Yeah, I don't see any issue in that code. But even if there were - it's all safe arrays so should've thrown a deterministic OutOfBounds Exception?

Although, it's nice that stack-allocated array can potentially highlight unprotected out of bound access 🙂

Hmm, maybe that's not it

Yeah, I don't see any issue in that code. But even if there were - it's all safe arrays so should've thrown a deterministic OutOfBounds Exception?

Although, it's nice that stack-allocated array can potentially highlight unprotected out of bound access 🙂

It was this bit, though I suppose it's ok...?

Looks like the issue is that we embed the wrong method table in a stack allocated array where the array method table is a runtime lookup. The array is span captured so wasn't getting stack allocated before this PR.

Why this only fails on arm32 is a good question (the failing method is tier0->fullopt, so it's not PGO related).

Before helper expansion we have:

STMT00024 ( ??? ... ??? )
N007 ( 27, 23) [000083] DACXG+-----                         *  STORE_LCL_VAR int    V03 loc2         d:2 $217
N006 ( 27, 23) [000080] -ACXG+-----                         \--*  CALL help int    CORINFO_HELP_NEWARR_1_OBJ $275
N002 (  3,  3) [000841] DA--G+----- arg0 setup                 +--*  STORE_LCL_VAR int    V123 tmp116      d:2 $VN.Void
N001 (  3,  2) [001114] -----------                            |  \--*  LCL_VAR   int    V142 rat8        
N003 (  1,  1) [000842] -----+----- arg0 in r0                 +--*  LCL_VAR   int    V123 tmp116      u:2 (last use) $274
N004 (  3,  3) [000740] -----+----- &lcl arr in r2             +--*  LCL_ADDR  int    V91 tmp84        [+0] $30a
N005 (  1,  2) [000072] -----+----- arg1 in r1                 \--*  CNS_INT   int    1 $57

and this produces the following method table store:

***** BB47 [0106]
STMT00231 ( ??? ... ??? )
N003 (  9, 14) [001367] nA--G---R--                         *  STOREIND  int   
N002 (  3,  3) [000740] -----+-----                         +--*  LCL_ADDR  int    V91 tmp84        [+0] $30a
N001 (  2,  8) [001366] H----------                         \--*  CNS_INT(h) int    -0x10255E14 class System.__Canon[]